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1 ABSTRACT OF THE DISCLOSURE 

2 

3 A method is described which simplifies, automates and organizes the creation of notes and 

4 correspondence and also, by performing the calculations needed to determine the 

5 appropriate billing codes, provides documentation for billing purposes, and assists the 

6 health care worker in determining the proper billing code. An embodiment of this to 

7 facilitate the creation of documents in the setting of patient care is described. The 

8 embodiment also allows one to enter information into a patient database at the same time 

9 that one is entering clinical information for the purposes of clinical care documentation. 

10 The database could be for clinical care, quality assurance, or research purposes. The 

1 1 embodiment describes how this can be achieved at the time that a service is delivered, for 

12 example when a health care worker sees a patient. Because the data is entered at the time 

13 of service, time is saved, and the information is more accurate. The invention allows one 

14 to enter information about patients using a combination of checklists, menus, and fill in 

15 the blank formats. The invention could use any handheld computer or desktop computer. 

16 Data entry also could be accomplished using scanner-enabled paper forms similar to those 

17 used by questionnaires or by tests such as the Scholastic Aptitude Test, with the user 

18 filling in the appropriate circles or other spaces to indicate the answer. Although the 

19 embodiment described references health care, this could be used in any industry. 

20 CROSS-REFERENCE TO RELATED APPLICATIONS 

21 Not applicable 
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1 

2 STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR 

3 DEVELOPMENT 

4 Not applicable 

5 

6 REFERENCE TO A MICROFICHE APPENDIX 

7 Not applicable 

8 

9 BACKGROUND OF THE INVENTION 

10 There has been considerable concern over the past few years regarding the 

1 1 expansion in the amount of medical information available in general as well as with 

12 respect to individual patients. At the same time as there are increasing pressures on 

13 health care workers to document as fully as possible, there are pressures to provide care 

14 as efficiently as possible. In general, care is given to a patient and the health care worker 

15 afterwards writes a note in a chart, or dictates a note, describing the activity. This 

16 information typically is entered in a relatively free form fashion. While this is useful and 

17 important as a way of preserving certain kinds of clinical information, it impedes medical 

18 care at other times because of the lack of standardization of terms and concepts. Finally, 

19 when notes are hand written they are often difficult for others to read. 

20 Increased documentation is being requested by third party organizations. The lack 

21 of structure within medical notes often results in an increase in accounts receivable for care 
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1 givers (that is, an increase in the backlog of bills which haven't been paid). This is because 

2 questions are asked about a rendered service, the chart needs to be found, the appropriate 

3 information extracted, and information sent back to the payer. Individual practitioners, 

4 academic institutions, pharmaceutical companies, and others in the health care industry 

5 have an interest not only in gathering patient related information but also in assessing the 

6 quality of the care, and in developing new methods of care. The Health Care Financing 

7 Administration (HCFA) a branch of the United States Department of Health and Human 

8 Services, in keeping with this trend, has published, in conjunction with the American 

9 Medical Association, a list of detailed requirements for billing at various levels. 

10 Health care providers would like to document the care they give as efficiently and 

1 1 accurately as possible. However, today a health care worker typically must indicate the 

12 results of the encounter, given current methods, after the patient is seen. This increases the 

13 burden on the individual health care provider. It increases the cost of gathering the data, 

14 regardless of whether information is entered by the original provider or by someone else. 

15 Because memory is faulty, even recent memory, it increases the likelihood of errors (both 

16 mis-statements and omissions). 

17 There has been a general increase in automation over the past several decades as a 

18 way of meeting some of these needs. For medical care, a number of companies and 

19 medical institutions have developed electronic medical information repositories. On the 

20 simplest levels, these repositories, often called electronic medical records or electronic 

21 patient records, include clinical notes, discharge summaries, and operative notes, all of 
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1 these the result of dictation. Laboratory reports also are typically included. The advantage 

2 of these repositories is that notes are in a legible form since they are dictated by the 

3 practitioner and then "typed." Moreover, they are stored in a common repository so that it 

4 becomes easier to find all the information, or at least much of the information, on a given 

5 patient. The disadvantage is that the information in many implementations is free form. 

6 Thus specific items of information are harder to find. This in turn means that the goals of 

7 clinical studies or clinical research are not met. If payers request specific kinds of 

8 information the information must be sought by a close reading of the text with automation 

9 relatively difficult. If information is to be obtained, diagnoses made, and care administered 

10 according to a protocol, there is no way of ensuring that this has occurred in the case of an 

1 1 individual patient without actually reading the record. 

12 Finally there are no ways of enhancing or facilitating data entry. Even though 

13 dictation is faster than writing, it usually is done at a time after the patient is seen and can 

14 be quite time consuming. To meet these needs, a number of companies have introduced 

15 systems for entering medical information through the use of organized menus. The user 

16 chooses from a list or lists the items pertinent to the visit. The computer program then 

17 develops a chart note based upon the choices entered. The disadvantage of this has been a 

18 lack of physician acceptance: many feel constrained by the programs, feel that they are 

19 more time consuming than dictation, and that the available choices do not reflect important 

20 aspects of the patient encounter. 
21 
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1 PRIOR ART 

2 Electronic medical record development has been the subject of both commercial 

3 and academic interest for decades, but no current method has been entirely successful. 

4 Most require the health care worker to be at a personal computer, or computer terminal. 

5 There are a large number of such programs. (Logician from MedicaLogic and 

6 HealthMatics Series 4 from HealthMatics are two examples). The disadvantage of these is 

7 that much of medical care is mobile: the doctor is walking around the hospital, the nurse is 

8 going from patient room to patient room, the home health care worker is going from home 

9 to home. Although one could carry a laptop computer, these are relatively large. Consider 

10 what the health care practitioners do when seeing or caring for patients. They need often to 

1 1 carry several diagnostic tools, medications, pieces of equipment, etc. They need to have 

12 both hands free to diagnose or care for the patient. A laptop is one more thing to carry. 

13 Furthermore, laptop might need to be opened up and closed as each patient is seen, even if 

14 it can be turned on instantly. There needs to be a place to put the laptop when it is used, 

15 and often there are no available surfaces. A large stationary computer or computer terminal 

16 (if there is space for one) would require a more elaborate and lengthy sign-on process each 

17 time to assure security of patient information, and to insure that the right person is 

18 accessing the computer or computer network. Also, in many patient settings, a large 

19 computer terminal and keyboard might be considered intrusive by the patient, and might 

20 actually impede the development of an appropriate relationship with the patient. 

21 Conversely, and perhaps perversely, the patient might find the device intriguing and 
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1 interesting, and would want "to take a look" - a look which would take time away from 

2 considering the patient's problems and which would make the overall use of the 

3 practitioner's time less efficient. To address the size problem, several companies have 

4 developed methods of using portable handheld computers for entering data on patients. 

5 One example would be Pocket Chart from Physix, Inc. which can use Windows CE based 

6 handheld computers. Another is Mobile MedData, made by Medical Communications 

7 Systems, which can use PalmPilot handheld computers. 

8 Feldon and Agrawal have described an "Electronic Documentation System for 

9 Generating Written Reports" (U.S. patent # 5,732,221). The preferred embodiment of 

10 Feldon and Agrawal invention uses a GridPad, a larger pen-based system. This includes a 

1 1 method for defining menu items and then a method for displaying these items in menus. It 

12 defines items such as titles, nouns, pronouns, and adjectives from which the user selects to 

13 generate a report. Based on the selections by the user, a written report is generated. 

14 Haessler, Elshtain, and Holland have described a "System and Technique for 

15 Automated Medical History Taking" (U.S. Patent # 4,130,881). This uses a branching 

16 method to assist in automatically taking a history from a patient. When particular answers 

17 are given, the system then asks pertinent related questions. The patient does this, so that the 

18 answers later are available to the physician. Such a system could gather initial pertinent 

19 positive and negative information for the health care provider. 

20 Similarly, Goltra has described a method for "Creating and Using Protocols to 

21 Create and Review a Patient Chart" (U.S. Patent # 5,794,208) and "Phrasing Structure for 
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1 the Narrative Display of Findings" (U.S. Patent # 5,802,495). The first of these discloses a 

2 method for developing disease or symptom-specific protocols for examining a patient. This 

3 is accomplished by submitting features of the patient's history and examination (for 

4 example) to a database. Based on the findings, the database develops a disease specific 

5 examination protocol. This protocol could then be utilized on a computer to indicate the 

6 results of examining the patient. The second discloses a method, based on the health care 

7 professional's findings, for generating the text of a narrative report of the examination. 

8 Dome has disclosed "System and Method for Correlating Medical Procedures and 

9 Medical Billing Codes" (U.S. Patent # 5,325,293). This is a method for collecting all of the 

10 aspects of a radiological examination so that the total billing code can be calculated. 

1 1 ("Procedure" is a term used in health care to denote radiological examinations, surgical 

12 operations, and similar methods of diagnosis or treatment.) Milstein, Maguire, and Meier 

13 have disclosed "Method for Computing Current Procedural Terminology Codes from 

14 Physician Generated Documentation" (U.S. Patent # 3,483,443). This method displays "a 

15 set of queries to the medical professional" and determines the appropriate coding level 

16 based on the results of these queries. 
17 

1 8 SUMMARY OF THE INVENTION 

19 While all of these methods include ways of documenting medical care, they all have 

20 in common a need to navigate through several layers of menus and submenus. Navigation 

21 through multiple menu layers is time consuming and can take the users attention away from 
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1 caring for the patient. Furthermore, not everyone feels comfortable using computers, even 

2 small computers, and in navigating menus. Finally, the best time to be certain that a 

3 particular patient encounter is well documented is at the time of the encounter, not later. 

4 However, the reason for the patient encounter is to take care of the patient, not to generate 

5 the bill. If at all possible, billing should not distract from patient care. The present 

6 invention integrates billing documentation into the process of documenting the history and 

7 physical examination. It allows written reports and also allows for reports to be generated 

8 in more than one format. For example, reports to patients and to professional users could 

9 differ from one another, as might be appropriate for the particular kind of correspondence. 

10 The invention described here also allows for generation of information for multiple needs, 

1 1 including correspondence, patient care, quality assurance, and research. 

12 The method described here uses, as an embodiment, a small and inconspicuous 

13 portable handheld computer but also could use paper or use desktop computers if preferred 

14 by the practitioner, or if more appropriate for a given situation. The format allows the 

15 health care worker to choose from short lists or to check appropriate boxes, with these 

16 organized in the order in which the particular health care worker is accustomed to acquire 

17 the information. The health care worker can modify the order of data entry. 

18 As noted, there are commercial products that use hand held devices. Some require 

19 text entry into the device, and this is cumbersome in the setting of clinical care. At other 

20 times, methods use more "formatted" data entry, but the layers of menus and submenus 

21 often are confusing for health care workers, and the time to navigate the menus can be 
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1 substantial. The invention described here allows both form driven and free text entry 

2 (including entry by dictation), and allows form driven data entry to be integrated with free 

3 text at a later point in time. It avoids the use of layers of menus. It allows the user to 

4 decide the order of data entry when the patient is seen. Patients have long experience with 

5 physicians taking notes on paper (using either blank pieces of paper or forms). No menu 

6 system will ever allow one to capture all of the important nuances of the problems of an 

7 individual patient The invention herein described allows not only free text entry into the 

8 computer or handheld computer but also free text entry by means of writing or dictation. 

9 The invention allows free text and menu driven information to be integrated afterwards. 

10 Finally, the present invention differs from its predecessors in that it explicitly combines the 

1 1 HCFA regulations into the broader set of all the history, physical examination, and patient 

12 care items that might be part of a given patient evaluation. The same can be accomplished 

13 easily for any other third-party regulations pertinent to medical care documentation. The 

14 invention creates a complete structure of the patient history and physical examination. It 

15 does this in a way that allows easy "maintenance" so that new elements can be added, and 

16 so that, as regulations for documentation change, the implementation within the invention 

17 can be modified easily. 

18 Rather than developing an overly complicated format that includes increasingly 

19 more possibilities, this method tries to provide a simple format, to which more information 

20 can be easily added. (See below and illustrations) Finally this invention allows output that 

21 can provide clinical research, quality control, or patient care data base information, clinical 
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1 notes, correspondence, and billing information, all at one time and without further 

2 intervention unless desired. 

3 The invention employs a system that allows the practitioner to encode a high 

4 percentage, perhaps three-quarters or more, of the information from a patient encounter in a 

5 simple fashion. The invention uses a combination of entry formats such as check boxes 

6 and lists, and avoids the use of multiple layers of menus. Rather, it allows the health care 

7 worker to move in a relatively linear fashion through the history and examination process. 

8 The invention takes advantage of the fact that what is done in the case of a particular 

9 encounter is fairly standard for the problem that generated the encounter. This is true for all 

10 health care workers, and in the case of physicians, for both for generalists and specialists. 

1 1 The invention includes questions that need to be asked in order to review the general 

12 medical state of the individual, includes items required under the HCFA documentation 

13 scheme, and includes methods for incorporating and identifying items that might be 

14 required by other payers or documentation schemes. All information is entered into a 

15 database. The invention allows development of data entry screens that relate to the data 

16 base tables. The invention allows the portable handheld computer to exchange information 

17 with any standard database 

18 (In the context of this submission, "dictate," "dictated," and "dictation" are meant 

19 to designate voice entry into either a desktop or portable recorder or into a computer with 

20 either later transcription by a human typist or by means of speech recognition. "Write" 

21 "writing" or "written" is meant to designate handwriting with either character recognition 
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1 or bit map capture subsequently. "Type," "typed" or "typing" is meant to designate any 

2 method of keying in information into a computer or typewriter that later will be or could be 

3 incorporated into a record.) 

4 Because no format can ever be expected to reflect the all the nuances of an 

5 individual patient encounter, the invention includes a method that allows the practitioner to 

6 indicate that dictation, or written or typed notes will be added. This is provided throughout 

7 the entry record, so that each addendum is linked to a specific part of the history, physical 

8 examination, or assessment and management process. The health care worker thus can 

9 note the majority of the pertinent information regarding the encounter while seeing the 

10 patient, and can note where dictation has been or will be added. The database engine can 

1 1 then generate a large percentage of the documentation, adding in any additional 

12 information that has been written, typed or dictated. When the user indicates that 

13 something is to be added, the invention also indicates how the added dictation or note fits 

14 into the HCFA (or other required) scheme. This then is a semi-automated rather than a 

15 completely automated format, because this is easier for the health care worker to use. It 

16 makes it easy for the user to "check off standard items and to "add in" items unique to the 

17 individual encounter. To give a simple example, a hospital nurse could use the invention to 

18 indicate a patient's temperature, pulse, and blood pressure, and later write down details of a 

19 specific question that the patient asked or request that the patient made. 
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1 The assumption is that the note would be customized according to a health care 

2 worker's mode of practice or care delivery or according to the type of patient the health 

3 care worker was seeing. 

4 As indicated above, the invention goes through all of the items that are important 

5 for documenting compliance with HCFA regulations. The information entered is used to 

6 help determine and justify the billing level for the individual patient encounter. Where 

7 made necessary by HCFA or other regulations, it asks the physician questions needed to 

8 justify a given level of billing. It provides all the information necessary for the computer to 

9 determine what the appropriate billing level might be and also provides the information 

10 needed to justify that level of billing. This is important because the new HCFA rules both 

1 1 are detailed and are complicated to apply accurately in a patient encounter setting. On the 

12 other hand, the rationale behind the system is reasonable. It is that different kinds of 

13 encounters take different amounts of time and intellectual effort and therefore should be 

14 compensated differently. Because its simple design allows denoting findings quickly, the 

15 invention can be used when there are time pressures. The invention does the same for any 

16 other third party regulation or documentation requirement. 

17 The rationale for this aspect of the invention is the following. The HCFA scoring 

18 system is complex, but it can be reduced to an algorithm. The algorithm is too complex for 

19 clinicians to calculate levels reliably in the course of a busy practice. Clinicians can be 

20 expected, however, to know what they actually do. Develop a simple means to allow them to 

21 document what they are doing when they do it. Allow them to use a simple check list format 
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1 which will interfere as little as possible with clinical care. Make this microprocessor based so 

2 that the check list responses "fill in the blanks" of a database. Develop an algorithm that 

3 checks responses in the database and uses these to "score" the patient encounter. The 

4 microprocessor then can calculate the billing level based upon the algorithm. This would 

5 simply documentation, assure greater accuracy, increase consistency among physicians and 

6 over time, and facilitate chart reviews. It would allow the physician to concentrate on medical 

7 practice, and allow the billing and billing documentation to be an outgrowth of the 

8 documentation of the patient encounter, rather than its central organizing principle. As an 

9 additional benefit, the checked off items can be used to prepare at least a portion of the 

10 physician's note automatically, saving the physician's time. 

11 The example given is of a physician, because of the DG. However, the same 

12 principles apply to notes prepared by nurses and other health professionals. Not all, but a large 

13 portion of a health care worker's documentation can be systematized, so that documentation 

14 can be prepared automatically. Going further, the principles described here can be applied to 

15 other industries where 1) data are acquired on the basis of an interaction between two or more 

16 people; 2) it is advantageous for data acquisition to be as unobtrusive as possible; 3) analysis 

17 of the acquired data is then expected; and 4) correspondence and other documentation are 

1 8 derived from this data. 
19 

20 
21 
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1 . Take the case of a person being seen for the first time in an outpatient setting. The 

2 patient could be registered prior to being seen by a physician. This part of the registration 

3 process would include putting the patient's name, phone number, age, and other 

4 information into a database. This information would then be downloaded to the 

5 physician's portable handheld device, desktop computer, or paper form, depending upon 

6 the practitioner's preference and need. The invention includes questions about the patient's 

7 medical history, information about the results of physical examination, questions about 

8 medication, diagnostic options, medications, plans, and the like. It includes questions 

9 regarding the complexity of the problem that are important for medical billing purposes. 

10 The invention allows the health care worker to indicate whether additional information has 

1 1 been or will be added by dictation, writing, or typing. The invention provides a way for the 

12 health care worker to indicate what other activities were part of the encounter. (For 

13 example, looking at films or laboratory reports effect billing levels for physicians.) The 

14 results of the data entry can then be exchanged with the data base host. The data base host 

15 generates the clinic note and the letter and also generates the information regarding the 

16 intensity of service, which is needed for determining the billing level. The data base host is 

17 a figurative concept. In execution it could be either a single program, or several related 

18 programs. For example, the calculation of billing level could take place on a portable 

19 device, if this is used. It also could take place on a desktop computer or network server 

20 after the information is uploaded from the portable device. Generation of notes or 

21 correspondence regarding the encounter could take place at the same time that billing level 
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1 is calculated, or as part of a separate operation, depending upon the specific needs of the 

2 particular patient, encounter, or practice. 

3 The discussion above emphasizes the use of this in documenting compliance with 

4 the HCFA/AMA documentation guidelines (DG). However, the intent of this invention is 

5 that compliance documentation be one of the results of use of the invention, but not the 

6 only use. The principle underlying this invention is that the proper focus of the health care 

7 worker's time should be on providing and documenting an encounter in the interest of 

8 patient care, not in the interests of reimbursement alone. The compliance documentation 

9 with respect to reimbursement is the result of the documentation, but not its sole focus. The 

10 idea behind the invention is to simplify the documentation process, and make notes 

1 1 documenting patient encounters easier to read, organize and find. The ability to document 

12 compliance with DG is an outgrowth of this process, but not its central focus, from the 

13 perspective of the user. 

14 In addition to obtaining a history, performing a physical, and deciding upon a 

15 course of action, the physician must convey the course of action to the patient. This is done 

16 in part by writing prescription, but also by discussing patients' problems and questions 

17 with patients and their families. In many cases, the physician may wish to provide written 

1 8 information that the patient can take home or may wish to document important elements of 

19 the conversation in the medical record. The invention allows the clinician to indicate, in a 

20 simple way, the items that have been discussed. The software text engine within the 

21 invention can then summarize these discussions, and can select items of information that 
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1 should be provided to the patient. These items can be developed ahead of time by the 

2 clinician, or could be purchased from others. The invention thus allows information to be 

3 documented for billing purposes, to be sent to other health care workers, and to be provided 

4 to the patient in a simple and straightforward manner. Depending upon the desires of the 

5 physician, the same information can be sent to everyone, or the information can be 

6 customized based upon the needs of the individual recipient. Similarly, the physician can 

7 identify prescriptions that should be sent to a pharmacy, and these can be sent 

8 automatically. 

9 According to DG, if "counseling" takes more than 50% of the time of the 

10 encounter, time alone can be the basis of the billing, if properly documented. The 

1 1 invention includes timing mechanisms to help determine if this is an appropriate basis for 

12 billing, and mechanisms for documenting the time and counseling appropriately. 

13 In the setting of a teaching hospital, DG provide that an attending physician can 

14 utilize the documented observations of a resident. However DG also make clear that the 

15 attending physician must be explicit regarding what elements of the resident's history and 

16 physical are used and must note any differences between the resident's and attending' s 

17 evaluation. The invention facilitates this. If the resident has seen and documented a patient 

18 encounter using the invention, the results of this encounter can be reviewed by the 

19 attending in the same way. The attending can indicate what features have been reviewed, 

20 what features have been personally examined by the attending, what differences there are 

21 in the attending' s assessment as compared to the resident's assessment. This simplifies the 
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1 documentation process and also assists in the training process, since messaging 

2 mechanisms can be utilized to explicitly indicate the differences to the resident. 

3 Communication could be through the database used by the institution or practice. One 

4 alternative would be that the resident "send" the data to the database and the attending then 

5 "get" this same data. If both resident and attending use appropriate handheld computers, 

6 there also could be direct infrared transfer between devices. 

7 Whether or not the patient is seen in the setting of a teaching hospital, the invention 

8 facilitates referrals, since a referral note is but another type of note to be sent. The referral 

9 note can be generated from the entered data in much the same way as a chart note or letter 

10 is generated. The reason for the request can be "checked off or written in a manner in 

1 1 keeping with the regulations. 

12 The above gave the example of a portable handheld computer. Clearly, if this can 

13 be accomplished on a portable device, those skilled in the art can readily see that it can be 

14 accomplished on a desktop computer. More broadly, then, the method could be used on 

15 any system which included: a) a "user interface" (a method for the computer to present 

16 information to the user, such as a computer screen); b) a way of storing data and program 

17 instructions (such as a computer hard disc); and c) a means for the user to communicate 

18 with the computer (such as using a mouse, a pen input handheld computer, a keyboard, or 

19 voice dictation). The same also can be accomplished using scanner technology. In this case 

20 the "questionnaire" is on a piece of paper and the user would then use a pencil or pen to fill 
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1 in the appropriate circles or squares. The paper would be scanned into a computer and the 

2 entered data would then be dealt with in a similar fashion. 

3 The present invention is a tool that the health care worker can use directly, but the 

4 patient could use an embodiment of the invention as well. The invention can receive 

5 information previously entered, be that information entered by the patient (as suggested by 

6 US Patent #4,130,881, mentioned above), or entered by another health care provider using 

7 the invention described here or another method of information entry. Going further, the 

8 spirit of the preferred embodiment is as follows. In most contemporary health care settings, 

9 there are existing standards and software that have been and are being used. The invention 

10 uses standard methods of obtaining, storing, and transmitting data. This facilitates 

1 1 integration of the invention into the broader setting of health care delivery within a given 

12 practice or institution. It also facilitates communication with third party payers, or with 

13 other institutions. For example, the database could be a standard commercial database, 

14 easily available to others, and the database storage would be such that a user familiar with 

15 database design and structure, or using standard tools, could easily examine its contents. 

16 The invention is compatible with UMLS (the Unified Medical Language System of the 

17 National Library of Medicine), The Arden Syntax for Medical Logic Modules (developed 

18 in part by ASTM, the American Society for Testing and Materials), SNOMED 

19 (Systematized Nomenclature of Human and Veterinary Medicine, College of American 

20 Pathologists), and other standard tools that integrate medical terms into a framework that 

21 allows them to be related to one another in a systematic and standardized way. 
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1 There is a problem with current computerized patient records, as well as with 

2 computer software in general which uses what is commonly called a graphical user interface 

3 or GUI. This is that the user often must navigate through a series of levels in order to get to a 

4 certain function or enter a certain type of information. The problem is that the clinician 

5 doesn't have the time to navigate down through layers of menus and submenus to find a given 

6 choice. This layering tends to discourage use of the form. 

7 This complexity may in part have developed because of a wish that the form be as 

8 complete as possible. However, this completeness results in an increased complexity of use. 

9 Data entry formats must be simple to use. If they are not, people won't use them. The concept 

10 of the present invention is that a large percentage of the history and physical, perhaps 70% or 

1 1 more, lends itself to entry into simple data entry formats such as described here. The balance 

12 does not. This invention does not expect all to be entered by means of a form. Because it does 

13 not, the form is easier to use. Dictation, typing, or similar means can enter the balance. Data 

14 entered by form can be blended easily with data entered by dictation or typing using the 

15 methods described. As voice and handwriting recognition and similar techniques begin to be 

16 used, such information will be able to go immediately into the appropriate portion of the 

17 database. 

18 Although the embodiment described here refers specifically to the health care 

19 industry, those skilled in the art will envision that this method would be applicable to other 

20 industries that require detailed data entry, and calculations based on the entered data. Such 
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1 adaptations and modifications are envisioned as being in the spirit of the invention and thus 

2 part of the invention. 

3 

4 BRIEF DESCRIPTION OF THE DRAWINGS 

5 

6 Figure 1 . The major elements of the Medical History and Physical as defined by the 

7 American Medical Association and Health Care and Financing Administration (available 

8 over the Internet at http://www.hcfa.gov/medicare/mcarpti.htm). 

9 Figure 2 and Figure 3 outline the system design. 
10 

1 1 Figure 4 indicates the flow of information as embodied in the invention. 
12 

13 Figure 5 demonstrates sample data entry screens from a preferred embodiment. 

14 

15 The drawings refer specifically to physicians, but the invention presumes that 

16 similar guidelines will be developed for other health care workers, either by governmental 

17 agencies, or locally, because of Critical Path or other diagnosis and care initiatives. 
18 

19 DETAILED DESCRIPTION OF THE INVENTION 

20 

21 Figures la-lh summarize the elements of the medical evaluation as codified by the 

22 Health Care Financing Administration (HCFA) and American Medical Association (AMA). 

23 This document is titled "Documentation Guidelines for Evaluation and Management 

24 Services." This disclosure refers to this as DG. 
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1 The overall concept is to divide the process of evaluation and diagnosis into a number 

2 of elements. DG attempts to score all of the elements reflected in the record of a particular 

3 assessment. Based upon all of the sub-scores (derived from the individual elements of the 

4 examination) the system then requires the practitioner to come up with an overall "score" 

5 which reflects the level of effort and which itself is the code which will lead to billing and 

6 reimbursement. As will be seen, the scheme is complex. Figures summarizing this scheme 

7 are included because it is important to have an understanding of the intricacies of the scheme 

8 if one is to understand the role of the invention in simplifying application of the scheme. One 

9 can readily appreciate that DG, like all regulations, are likely to be modified over time. The 

10 invention simplifies the process of modifying reporting of an encounter so as to comply with 

1 1 new regulations. 

12 The history is divided into the history of present illness per se, the review of 

13 systems, and the past, family and social history. The physical examination can comprise 

14 one or more of 7 body areas or 12 organ systems. Complexity of medical decision making 

15 pertains to the number of options available, the risks to the patient of the illness, diagnostic 

16 procedure, or treatment, and the type, amount, and complexity of data which need to be 

17 evaluated during the encounter. 

18 Figure la indicates that the three elements, as defined by DG, are history, physical 

19 examination, and medical decision making. The three major elements are further subdivided. 

20 Figure lb focuses on the defined elements of the history. In particular, 8 elements of 

21 the history of present illness have been defined. The practitioner is expected to make clear 
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1 which element(s) of the history are reflected within each part of the chart note. There then is 

2 scoring, based on the number of elements documented in the note. For example, if the note 

3 indicates the duration of a problem, the context in which it occurs, and factors which modify 

4 it, there would be three elements within the history, and it would be defined as a brief history. 

5 However, if the problem were a chronic problem, it would be considered an extended history. 

6 Figure lc shows the defined elements of the review of systems. There are 12 body 

7 systems defined by DG. Once again there is a scoring system, based upon the number of 

8 systems which are documented in the medical record. 

9 Figure Id shows the past, family, and social history scoring system. There are no 

10 specific elements defined at this time for any of these three. The scoring is based upon how 

1 1 many of the three are reviewed in the record. For many physicians, the order in the regulations 

12 is different from the one traditionally used for notes. For example, the review of systems 

13 often comes after the past history. DG indicates that, in the actual note, the elements need not 

14 be in the order used in the regulations. However, physicians may be tempted to do it in this 

15 way, to make it easier for chart reviewers, who are not necessarily physicians, and who may 

16 or may not have previous health profession backgrounds. The invention would allow 

17 information to be entered in one order and then extracted in that order or others:, the needs of 

1 8 patient care and of patient billing may be different. 

19 Figure le shows how the "sub-scores" shown in figures lb-Id are put together to form 

20 an overall score for the history. In order to achieve a given scoring level, each of the three 

21 parts of the history must be at least at the level stated, but it is permissible for the "score" to be 
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1 higher than the stated level. In other words, a detailed history must contain at least an 

2 extended history of present illness, at least an extended review of systems, and at least a 

3 pertinent past, family, and social history. 

4 Figure If summarizes the scoring system for the physical examination. DG 

5 distinguishes between specialty system examinations and what is called the general multi- 

6 system examination. Nine specialty examinations are defined. For illustrative purposes, 

7 figures lg and lh indicate one such specialty examination, the neurological examination 

8 Figure If shows the scoring for the physical examination. Once again, there are 

9 several levels of examination, depending upon the number of systems of specified types that 

10 are assessed. For example, a detailed examination must include 12 bulleted elements, a 

11 comprehensive examination all bulleted, all shaded, and one unshaded element. The scoring 

12 for the physical examination varies among the various examination types (general 

13 multisystem examination and the nine specialty examinations; figure lfl illustrates this 

14 schematically). The physician is expected to know the distinctions and perform the correct 

15 examination for the correct type of patient. A specialist, who might only learn one 

16 examination, could learn this, but it is more difficult for a primary care doctor, who sees many 

17 different kinds of patients, to accomplish this. It also presents difficulties for residents who 

18 rotate among services as a part of their medical training and who need to learn clinical 

19 medicine, let alone the intricacies of the DG system. The invention takes care of this for the 

20 physician. After the physician indicates what has been tested, and what kind of patient 

21 encounter is occurring, the invention determines the proper coding for this encounter, based 
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1 upon the rules in the DG. The algorithm within the invention is flexible and can be easily 

2 modified to accommodate changes in the rules of the DG, or different rules from other third 

3 party agencies, such as insurance companies. The invention also can educate. For example, it 

4 can indicate what elements are needed for a given level of billing within a given type of 

5 examination. 

6 Figure li reviews the elements of what DG calls medical decision making (MDM). 

7 This portion of the scoring system divides into three subgroups. The first group within MDM, 

8 called the "number of diagnoses or treatment options," pertains to the kind of problem the 

9 patient has. For example, the problem can be self-limited, can be a problem known to the 

10 clinician, can be stable or can be worsening. The second group relates to the "amount or 

1 1 complexity of data to be reviewed." For example, does the clinician have to review laboratory 

12 tests, radiological studies? Does the clinician have to review old records or personally view 

13 images, traces of laboratory specimens? The third group seeks to summarize the "risks" to the 

14 patient of the disease, diagnostic tests, or treatments. DG provides suggestions regarding how 

15 to code for each of these groups and there is a table to help in coding risk (figure lj reproduces 

16 this from DG). 

17 It is important to note that this table gives representative examples but does not cover 

18 all situations. To give another example, the instructions for the first MDM group (not shown; 

19 this is a component of li) includes a category for an established problem which is stable or 

20 improved and one for an established problem that is worsening. However, "stable or 

21 improved" implies that things are going relatively well. What if a problem is bad, and remains 
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1 bad? What is the appropriate category? There are additional examples throughout the DG. The 

2 invention allows clinicians to customize this table to match their practices and patient 

3 populations. Clinicians, practices, or institutions then could, for example, inquire to HCFA 

4 regarding specifics of their coding, and easily change the coding rules to accommodate HCFA 

5 rulings. Similarly, if the rules change, the algorithm can change the coding, and resultant 

6 billing, which occurs, either for future patient encounters, or retroactively. 

7 The clinician is then expected to take the scoring from each of the sections just 

8 described and derive an overall score for the encounter with the patient. There are different 

9 rules for each of the 15 types of encounters defined by DG (for new hospital patient, new 

10 outpatient, established patient, consultation, etc.). In some cases there are three final levels of 

11 service to be scored, in other cases five. The rules for scoring the encounter for various 

12 service levels vary among the types of encounters, so that a given level of history, of 

13 examination, or of MDM could be scored differently for each of type of encounters. It can be 

14 seen the scoring system itself is complex, and it is clear that an inadvertent error might be 

15 made because of this complexity. 

16 Figure 2 outlines the basic system design. There is a patient encounter (2a) and it is of 

17 a particular type, such as: New Patient, Office; Initial Hospital; Initial Inpatient Consult. There 

18 are 15 possible encounter types currently. The health care worker indicates this at the time of 

19 the encounter. Alternatively, in the case of a scheduled encounter, such as an outpatient visit, 

20 or prior to rounds on inpatients, the patient name, hospital registration number and other 

21 demographics, and the type of encounter, could be entered into the database "form" ahead of 
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1 time. A history is obtained (2b 1) including the 8 elements of the "history of present illness, " 

2 the 15 elements of the review of systems (2b3), and the past, family, and social history (2b4). 

3 A physical examination (2c 1) is performed and this can include any of 7 body areas or 12 

4 organ systems (2c2). Medical Decision Making (MDM) (2dl) is composed of three 

5 subunits, the first related to number of treatment options (2d2), the second to data complexity 

6 (2d3), the third to risks of the medical problem, the diagnostic procedure, or the treatment 

7 (2d4). 

8 A score (2b5, 2c3, 2d5) is derived from each of these three sections (2b, 2c, 2d). A 

9 final score is derived from 2b5, 2c3, 2d5. There are 64 possible combinations for each of the 

10 15 types, for a total of 960 combinations. The rules for billing differ among these categories. 

1 1 The invention contains category specific algorithms to determine the appropriate billing level 

12 for the service provided. In some cases (new hospital in-patient, for example), there are 

13 minimum service levels that must be met before billing is allowable. The algorithm 

14 determines whether these minimum levels of service have occurred. In these cases, lower 

15 levels of service are not allowed during, for example, a hospital admission; higher levels of 

16 service are required. The invention would inform the physician when the information 

17 provided by that physician is not sufficient to justify billing. Similar scales have been 

18 constructed for the history, examination, and MDM sections. 

19 Alternatively, billing can occur solely based on time (2f), if counseling of the patient 

20 takes over 50% of the time of the patient encounter. There are separate rules for this. The 

21 invention includes multiple timers to allow appropriate determination of the time of the visit, 
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1 and of the counseling activities, as required by certain HCFA regulations and also potentially 

2 needed for time-and-motion documentation of a health care worker's activities. It also 

3 facilitates documentation of the counseling itself. 

4 An important feature of this invention is that all of the data entry elements, and all of 

5 the data output elements, can be customized by clinicians to meet the specifics of their 

6 practices. Data entry elements can be added to the sections for the history, physical, and 

7 medical decision making. These added elements can be linked in to the billing schema. 

8 Standard sections of output text can be defined and can be modified as needed for chart notes 

9 and correspondence. For example, there may be specific counseling that is performed 

10 routinely for a specific type of patient. The gist of the counseling could be summarized as a 

1 1 standard output text element that then could be included easily in the note. 

12 This is illustrated in figure 3. The invention as delivered to the user would contain 

13 default data elements to facilitate entry of information regarding the history, physical 

14 examination, and medical decision making (3a). It would also contain default billing 

15 algorithms (3b), and default text for correspondence (3c). The user can add elements to any 

16 section (an example is shown in 3e) and can define text output for these new elements (3g). 

17 The algorithm automatically adjusts for the presence of the new element (3f). In the example, 

18 there were four elements available and entered initially during a hypothetical encounter, one 

19 was added to the template. The user added an element (data element a, figure 3e). The user 

20 actually used all 5 of the elements now available when seeing a patient. The billing module 
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1 detected this and scored accordingly (3f). Text output was automatically created for the five 

2 elements. 

3 In addition, for both the original four and for the new group of five elements, the text 

4 output can be modified according to clinical needs or physician preference (3d, 3h). If the 

5 billing rules change, the coding can be changed to meet the new DG. The results of these 

6 changes can be applied either prospectively or retroactively. Retroactive changes can be for all 

7 previously entered data, or for only a subset, to conform to third party requirements (31, 3j). 

8 The physician enters the basic information for these sections. When appropriate, the 

9 system can ask relevant questions that help the algorithm to determine which elements to 

10 score. For example, the algorithm could ask (figure 2, 2d3) whether the physician is indicating 

1 1 what an x-ray report described or is describing the x-ray based on personal review. Such 

12 distinctions are important for billing purposes when using the DG schema. To give another 

13 example, the physician must state which type of examination was utilized (general 

14 multisystem, eye, dermatology, etc.). The system then scores the examination according to the 

1 5 requirements of the type of examination employed. 

16 As figure 4a indicates, the method stores information in a database. Entries into the 

17 database can be made in many ways. For example, one could use a computer-based form 

18 (4a 1), be the form actually on a computer, on a handheld computer, or on paper, e.g. a form 

19 that can be scanned. In this case, the form would be designed with checklists, and the like. 

20 The design of the form would be "flat," without multiple layers of drag down or pop-up 

21 menus and submenus, to facilitate speed and ease of use. Data also could be dictated, written, 
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1 or keyed into the database. In the case of dictation (4b2), this could be traditional dictation, or 

2 computer based dictation using voice recognition. The same concepts apply to writing. Data 

3 could be entered into a form or as free text (4a3). In these cases, the system is designed to 

4 indicate where in the overall documentation the dictated or keyed information would go. The 

5 dictation or keyed input is then linked within the database (4a4) to the forms based input. 

6 Depending upon the needs of the situation, the user could dictate, write or key the name of the 

7 input screen and item, or there could be a unique identifier for each input screen or for each 

8 item on the screen. With computer based input, there could be automatic linking. That is, the 

9 user would highlight an item, or a screen, and the next input into the system (e.g. dictation, 

10 keyboard) would be linked to that highlighted position on the screen. The database scoring 

1 1 would then include that item for billing purposes. Assume, for example, that the user chose to 

12 dictate the details of palpation of the liver (see figure 5d.) The user would indicate the item 

13 (by highlighting it, for example, on a computer screen, or by checking off a box indicating an 

14 addition on a computer or paper form). The database would then "register " the dictated or 

1 5 keyed text at the appropriate point in the database. 

16 More than one person might make entries regarding a particular medical encounter. 

17 For example, both the resident and the attending physician in a teaching hospital might 

18 prepare a note. In the case of a teaching hospital or a similar situation, the attending (e.g. 

19 4a4b) could review the entries of the resident (e.g. 4a4a), make changes as may be 

20 appropriate, indicate items personally assessed, and indicate that the data has been reviewed 

21 and corrected. This permits explicit documentation of the nature of the attending's review of 
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1 the resident's data entry, and also facilitates teaching, since the attending's edits of the 

2 resident's data entries could be "messaged" back to the resident. A similar mechanism could 

3 be used in the case of consultations. The consultant (4a4b) could explicitly review the 

4 requesting physician's note (4a4a). Where appropriate, a portion of the consultation report to 

5 the requesting physician could then explicitly be prepared in the context of the requesting 

6 note. 

7 The database then uses the entered data to prepare, and justify, billing (4a5). The 

8 method uses the database entries to prepare chart notes (4a6) and other correspondence (4a7) 

9 and to prepare prescriptions (4a8). The entries in the database can be used to place entries into 

10 other clinical (4a9) or research (4al0) databases. 

1 1 A feature of the data base design within the invention is the following. The DG may 

12 change, or there may be a reinterpretation of the DG by HCFA with a request that billing be 

13 recalculated based upon the new DG. In this circumstance, original records would have to be 

14 obtained and recoded given current methods. With the method outlined, recoding usually can 

15 occur in a simple manner by means of a simple change in the database tables followed by a 

1 6 structured query of the database. 

17 The database is designed so as to provide several types of output. As already 

18 described, it codes for the level of service so as to satisfy DG for billing. It also generates 

19 chart notes and correspondence. It can do this using standard templates built in to the system. 

20 For example, (figure 5b) a check on an item in the review of systems can generate an 
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1 appropriate comment in the note: check off arthritis and the note can say, "The patient has a 

2 history of arthritis." The physician can modify the templates according to personal preferences 

3 for documentation. All or a portion of the entered data can be used to populate a database 

4 used to monitor or facilitate clinical care, quality assurance, or research. 

5 Figure 4b illustrates the use of the database to provide both billing and text output. The 

6 example shows this for the elements of the history. The same principles apply to physical 

7 examination and medical decision making. 

8 As figure 4b shows, and as reflected in the DG, there are three basic elements to the 

9 patient encounter: history, examination, and decision making process (4b 1, 4b2, 4b3). The 

10 process employed by this invention is that the clinician enters data with regards to these three 

1 1 elements, entering the data either into a "form" (see figure 5 for an example) or by using free 

12 text (dictation, typing, etc.). The entered elements are joined together in the next stage. These 

13 can be joined to form a text note suitable for a medical chart, for dictation, etc. (4b4, 4b6, 

14 4b8). The invention also determines where the free text elements fit within the DG billing 

15 scheme (4b5, 4b7, 4b9). This is envisioned as a process wherein the user can indicate at the 

16 time of text entry where an element fits (e.g. by checking a box, see figure 5). Alternatively, 

17 the invention can ask the user-clinician at the time that the user-clinician reviews the 

18 completed questions pertinent to the DG. The idea here is to make these questions part of the 

19 dictation review process, a process the clinician already knows. In the case of notes, 

20 correspondence and the like, there are rules within the method for how the combination of 



Page 32 of 40 



1 form based entries and free text entries are to be converted to a final text document (4b 10, 

2 4b 12, 4b 14). Where desired by the user, the invention can list the points that the clinician 

3 wishes or needs to include within the dictation. The method also assesses the combination of 

4 form and free text entries to determine the billing level (4bll, 4bl3, 4bl5). The rules for 

5 conversion to a text document result in text output for each of the three segments of the final 

6 note (4bl6, 4bl8, 4b20). These three are then joined together into the final document (4b22) 

7 together with addresses, salutations, signature sections, patient name and chart number, date, 

8 and other standard elements for the text. The method includes a way for the user to customize 

9 these elements, or add new elements. It also has rules for the appearance of the final text, 

10 again customizable for each type of text output (4b23). Embodied within 4b23 is the concept 

11 of educational materials which could be sent, for example, to a patient to help underline 

12 discussion points that occurred during the office visit. The clinician thus can spend more time 

13 actually talking with the patient. There can be (previously prepared) items summarizing 

14 important points related to the discussion which has occurred. The clinician can "check-off 

15 the items which should be sent to the patient, to other health care providers, or to others, 

16 including insurers. Similarly, the method determines a code for each of the three elements of 

17 the patient encounter (4bl7, 4bl9, 4b21) and then determines the overall billing code (4b25), 

18 based upon the DG rules (4b24). The final text or texts (4b26) and final billing code or codes 

19 (4b27) are thus prepared. Those skilled in the art can see that health care workers not subject 

20 to DG, such as nurses, could use the invention to document the patient encounter itself in the 

2 1 same way. 
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1 An example of a table of values is shown in figure 4c, for initial hospital visits. The 

2 table is a codification of the Initial Hospital Care sections in Physicians' Current Procedural 

3 Terminology, Fourth Edition, CPT1998, published by the American Medical Association 

4 Column b row 2 shows 3/3, indicating that all three "scores" must be at the given level to 

5 justify a level of billing. Column c, row 1, shows the first four numbers of the billing code. 

6 The final number is listed below in the table as follows. The three elements, as noted above 

7 are A (history), B (Examination), and C (MDM). As described above, for history and for the 

8 examination there are four levels of effort (1 -problem focused; 2-expanded problem focused; 

9 3-detailed; 4-comprehensive). For MDM there similarly are four levels (1 -straightforward; 2- 

10 low complexity; 3-moderate complexity; 4-high complexity). The numbers 331, 1, and 30 in 

1 1 column d indicate that the minimum value for a final score of 99221, A must equal at least 3, 

12 B equal at least 3, and C equal at least 1. The table then looks at all possible combinations of 

13 A, B, and C and lists what the final code would be. It indicates the combinations (denoted by 

14 n in the example) for which services can't be billed. The method is so constructed to allow 

15 changes in the codes as changes in DM occur. Simply changing the values, scale, or table 

16 could accommodate a different schema, for example from an insurance company. An 

17 alternative way of determining the proper level of billing would be by the use of decision 

18 trees. Using this alternative, the algorithm at each point would ask whether the encounter has 

19 included a particular activity or set of activities. If yes, the algorithm branches in one 

20 direction, if no, in the other. Those skilled in the art will recognize that branching algorithms 

21 of this type, although explicit, can be difficult to maintain, since a small change in the DG 
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1 could require changes throughout the algorithm. A lookup table, such as used in this 

2 invention, is a simpler way for codifying the requirements of the DG and is simpler to 

3 maintain, and to check for errors. 

4 The methodology helps to reduce duplication of effort on the part of the clinician. 

5 Typically, when clinicians wish to follow the care of a population of patients, the data 

6 regarding these patients must be entered separately from, and generally after, the clinical note 

7 is dictated or written. The problem is that in the course of a busy clinical practice, clinicians 

8 are pressed for the time to enter the data the second time (for the database). Moreover, even 

9 with the best of intentions, data entered later is likely to be less accurate than data entered at 

10 the time of the patient encounter. Data entry personnel can be hired, but this increases the 

1 1 expense of care or of research. 

12 Figure 5 demonstrates sample data entry screens from a preferred embodiment. This 

13 embodiment was developed for a handheld computer, the PalmPilot, but a similar 

14 methodology is asserted for other handheld computers, for desktop computers and for paper 

15 formats. Figures 5a and 5b depict sample screens from a review of systems (ROS). Figure 5a 

16 lists questions for reviewing what are called constitutional symptoms, 5b, musculoskeletal 

17 symptoms. A check is placed in a box to indicate the presence of a symptom. If only one or 

1 8 two are present, and the rest are not, the clinician can indicate this in a simple way, without 

19 having to enter a check on each line. Alternatively (if desired) there could be two boxes, one 

20 to indicate that a symptoms is present, and another to indicate that it is not. (See figure 5i.) 
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1 The "all negative except as checked" could still be used. At the bottom left are a check box 

2 and the word "Notes." The check box is meant to indicate the concept, noted above, of 

3 indicating an addition to the form at the appropriate point in the form. The check would 

4 indicate that there was text to insert at this point. Alternatively, the word "note" is a button on 

5 the computer form. "Pushing" the button would take the user to a blank page where free text 

6 information could be entered directly. By highlighting an item and then pressing the note 

7 button, for example, the user indicates to the system that a note is to be added to that item. 

8 That added note could be highlighted, if desired, at the time the note is reviewed. In a similar 

9 way, if a resident or other caregiver has seen the patient before the attending, check boxes can 

10 be used so that the attending can indicate review of the previously entered information. 

1 1 Figures 5c and 5d show representative screens for the Constitutional examination and 

12 the Abdominal examination. The explanations in the previous paragraph again apply. There 

13 also are fill-in sections for blood pressure, pulse, and the like, or these could have been 

1 4 entered previously. 

15 For figures 5a-d, there are buttons at the bottom labeled Prev, Next, ROS, Exam, and 

16 Done. Previous and Next take the user to the previous and next screens for that portion of the 

17 evaluation. Exam and ROS take the user to the main screen for physical examination and 

18 Review of Systems respectively. Figure 5h gives an example of an ROS "main screen," listing 

19 all the possible systems to be reviewed. Pressing "Done" indicates that the user has completed 

20 that section of the evaluation (i.e. the ROS section). Note that there are relatively few items on 
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1 a given "page" and that all items are accessible without going into more than a single 

2 submenu or subform. 

3 Figure 5e shows a checklist for treatment plans for a patient. This particular set of 

4 forms was designed for use in an epilepsy clinic, so that the medications are anticonvulsants. 

5 The same principals would apply to any clinical setting, however. The user employs a check 

6 to indicate what the treatment plan is for the patient. If the physician has a standard way in 

7 which the medication is to be used, the check can generate, via the database, chart notes, 

8 correspondence, prescriptions, and patient educational materials indicating how the 

9 medication is to be used. Figure 5f shows a form for use in indicating drug doses. Figure 5g 

10 indicates various treatment options for patients who are candidates for surgical treatment for 

1 1 their seizures. 

12 In these examples, a standard protocol could be developed by, and be used by, the 

13 clinician. In such a case the check is sufficient to "trigger" the protocol. However, this is not 

14 required. As in the previous examples, the clinician could highlight an item and dictate 

15 additionally in regards to it. The clinician could prescribe the treatment in a "non-protocol" 

1 6 manner. A button or check box for notes also could be included. 

17 The data entry for this invention is as "flat" as possible, with a maximum of one 

18 submenu on any data entry page. The rationale is that a physician tends to ask a set series of 

19 questions, and perform a set series of tests, regarding a given problem. The data entry format 

20 seeks to mirror this process. Rather than navigating "down" to a submenu, the user touches 
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1 the "next" button to go to the next menu for that form. The user can arrange the order of the 

2 forms to conform to personal tastes and habits or to meet the needs of the patient encounter. 

3 As already noted, the same principles would apply to data entry by other health care workers, 

4 and by workers in other industries. 

5 While invention and a specific process for implementing invention have been 

6 described in detail, those familiar with the art to which this invention relates will see that 

7 various changes, alternative designs and modifications can be made therein without 

8 departing from the inventions spirit and scope, as defined by the following claims. Those 

9 skilled in the art also will appreciate that, although an embodiment in health care has been 
10 described in detail, the invention could be used in other industries. 
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1 What is claimed is: 

2 1 . A process to facilitate codified data entry at point-of-service, comprising: 

3 (a) entering information on data forms, said forms consisting of a plurality of 

4 items and with one or less submenu for any item, and said forms presenting 

5 said items to the user, 

6 (b) storing said entered information, 

7 (c) placing said entered information in data tables, 

8 (d) storing in data tables requirements for utilizing said entered information, 

9 (e) linking said entered information with said requirements, 

10 (f) comparing said entered information with said requirements, 

1 1 (g) determining requirements met by said entered information, requirements 

12 comprising requirements for billing, for text output such as correspondence, 

13 for quality control, for internal record keeping, 

14 whereby recording of point-of-service information and preparation of outputs including 

15 billing outputs, quality control outputs, internal record keeping outputs, and text 

16 outputs such as correspondence outputs are facilitated, automated and simplified, 

17 and 

18 whereby said requirements met by said entered information can be determined. 

19 2. A process according to claim 1 further comprising: 

20 (a) allowing said forms to be customized or changed to meet needs or 

21 preferences of individual users or organizations, 
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1 (b) allowing the order of presentation of forms to be customized or changed to 

2 meet needs or preferences of individual users or organizations, and 

3 (c) allowing forms to be opened in a predetermined order in an automated 

4 fashion. 

5 3. A process according to claim 1 further including: 

6 informing the user of requirements met by entered information. 

7 whereby the user is helped to ascertain that entered information meets said 

8 requirements. 

9 4. A process according to claim 1 further comprising: 

10 (a) questioning the user as needed to determine whether specific 

1 1 requirements are met, 

12 (b) entering into data tables answers to said questioning, 

13 (c) determining requirements met by the combination of said entered 

14 information plus user answers to said questioning, requirements comprising 

15 requirements for billing outputs, quality control outputs, internal record 

16 keeping outputs, and text outputs such as correspondence outputs 

17 5. A process according to claim 1 further including: 

18 (a) modifying said data tables so as to modify or update said requirements 

19 thereby forming new requirements. 

20 6. A process according to claim 1 further comprising: 

21 (a) entering said information into said forms by an input means of the user's 
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1 preference, selected from the group comprising desktop computers, 

2 computer terminals, laptop computers, handheld computers or devices, 

3 voice recognition devices or software, and scanable paper forms, 

4 (b) using a storage means to store said information and said requirements said 

5 storage means comprising a computer or computers, 

6 (c) allowing said input means to link with said storage means within a 

7 single device or by a method selected from the group comprising wireless 

8 connections, infrared connections, modems, local area networks, wide area 

9 networks, and internet connections, 

10 (d) using software means to join said information with said requirements within 

1 1 said data tables, 

12 whereby information can be entered by the method or methods most convenient to the 

13 user or most appropriate for the situation and then joined into a single common 

14 output. 

15 7. A process according to claim 1 further including: 

16 (a) linking within a database information entered into said data forms with 

17 narrative information or information not entered into said forms, including 

1 8 information entered by typing or dictation, 

19 whereby a single output can be prepared from information entered by multiple means. 

20 8. A process according to claim 7 further including: 

21 (a) generating from stored data outputs of multiple types, including billing 
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1 outputs, quality control outputs, internal record keeping outputs, and text 

2 outputs such as correspondence outputs, 

3 whereby health care and other service organizations, manufacturing organizations, 

4 or other businesses or person engaged in such occupations can acquire said 

5 information, store said information into said data tables, perform complex 

6 calculations based on information stored in said data tables, or prepare documents 

7 based upon said information. 

8 9. A process according to claim 7 for health care organizations and individual health care 

9 deliverers further comprising: 

10 (a) separating said forms into groups comprising patient demographics groups, 

1 1 medical history groups, past medical history groups, review of systems or 

12 review of symptoms groups, family history groups, social history groups, 

13 physical examination groups, medical decision making groups, counseling 

14 groups, treatment plan (including prescription) groups, 

15 (b) storing on said data tables said reporting requirements including federal and 

16 other government reporting requirements, insurance company reporting 

17 requirements, and other health care or health care organization reporting 

18 requirements, 

19 (c) scoring by software means said entered information according to said 

20 reporting requirements, 

21 (d) generating from stored data multiple outputs, including billing outputs, 
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1 quality control outputs, internal record keeping outputs including chart 

2 note outputs, prescription outputs, text outputs such as correspondence 

3 outputs, whereby said health care organizations and said individual health 

4 care deliverers can acquire said information, perform data storage, perform 

5 complex calculations based on said information, or prepare documents 

6 based upon said information. 

7 
8 
9 
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J. Mark Holland & Associate s 

From: <j_payne@ropakcorp.com> 

To: "J. Mark Holland & Associates" <office@jmhlaw.com> 

Sent: Thursday, May 22, 2003 12:54 PM 
Subject: Re: Ropak Trademarks 

Thank you. I recieved the package and have had a chance to review it. It 
is exactly what I need. 

I'm glad you mixed the dates as it made me question my listening skills (I 
had it as shown below). No problem. I've changed it 

Thanks again for the information. 

Sincerely, 
Jane E. Payne 
Director of Marketing 
Ropak Packaging 
(800) 367-3779 ext. 158 



"J. Mark 

Holland & To: Jane Payne <j pavne(5>ropakcorp.com > 
Associates" cc: 

< office@jmhlaw Subject: Ropak Trademarks 
.com> 

05/20/2003 
01:26 PM 
Please respond 
to "J. Mark 
Holland & 
Associates" 



Dear Ms. Payne: 

V\fe confirmed that the package we sent via FedEx arrived at Ropak Southwest 
this morning. Unfortunately, I mixed up the due dates on page two of our 
correspondence. The correct dates are as follows: 

Docket No. Trademark Due On or Before 

ROPAK-T1 855 EZ COVER May 27, 2003 

ROPAK-T1864 EZ DOES IT May 27, 2003 

ROPAK-T1 863 EZ STOR September 30, 2003 

ROPAK-T1854 EZ PAK October 21, 2003 

Please let us know if you have any questions. 

Mark Duncan, Paralegal 



06/02/2003 
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+ + + + + + + + + + + + + + + + ++ + + + ++ + + + + + + + 

J. Mark Holland & Associates, 

A Professional Law Corporation 
Telephone: (949) 718-6750 Facsimile: (949) 718-6756 
++++++++++++++++++++++++++++++ 

This is a private message for the intended recipient 

WARNING: PLEASE NOTE that, although we have made reasonable attempts to 
ensure that there are no electronic viruses in any attached documents, as 
with most types of electronic communication, there cannot be a 100% 
guarantee that files are not infected or otherwise corrupted. Accordingly, 
please use your discretion in opening and/or saving any attachments 
accompanying an e-mail message. Among other things, you should confirm 
whether the incoming message is from a trusted and reliable source, and 
probably scan messages and attachments with anti-virus software prior to 
opening it. Your MIS department will probably be able to advise you 
whether 

your e-mail program is configured to detect and remove viruses. 



************************************************************ 
***** ROPAK CORPORATION DISCLAIMER **** 

************************************************************ 

The information in this e-mail and any attachments to 
it are confidential. The contents may not be copied 
or used by anyone other than the addressee and 
must not be further disclosed without our permission. 
If you have received this e-maii by mistake, please 
notify the sender immediately and delete this e-mail 
and any attachments to it from your systems. 

WARNING: Although the company has taken 

reasonable precautions to ensure no viruses are 

present in this e-mail, the company cannot accept 

responsibility for any loss or damage arising from 

the use of this e-mail or any attachments to it. 
************************************************************ 

************************************************************ 
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